استراتژی‌های کشینگ فرانت‌اند: کش HTTP و کش Service Worker

در دنیای توسعه وب، بهینه‌سازی عملکرد وب‌سایت از اهمیت بالایی برخوردار است. یک وب‌سایت کند می‌تواند منجر به کاربران ناراضی، نرخ پرش (bounce rate) بالاتر و در نهایت، تأثیر منفی بر کسب‌وکار شما شود. کشینگ (Caching)، تکنیکی برای ذخیره و استفاده مجدد از منابعی که قبلاً بازیابی شده‌اند، نقشی حیاتی در بهبود سرعت وب‌سایت و کاهش بار سرور ایفا می‌کند. این مقاله یک نمای کلی جامع از دو استراتژی کلیدی کشینگ فرانت‌اند ارائه می‌دهد: کشینگ HTTP و کشینگ Service Worker.

درک مبانی کشینگ

کشینگ شامل ذخیره کپی‌هایی از منابع، مانند HTML، CSS، جاوا اسکریپت، تصاویر و دیگر دارایی‌ها، در مکانی نزدیک‌تر به کاربر است. هنگامی که یک کاربر منبعی را درخواست می‌کند، مرورگر یا یک واسطه کشینگ ابتدا بررسی می‌کند که آیا یک کپی کش‌شده در دسترس است یا خیر. اگر چنین باشد (یک «cache hit»)، منبع از کش ارائه می‌شود و از یک سفر به سرور اصلی جلوگیری می‌کند. این امر به طور قابل توجهی تأخیر را کاهش داده و زمان بارگذاری را بهبود می‌بخشد.

چندین سطح از کشینگ وجود دارد، از جمله کش مرورگر، کش پراکسی و کش سمت سرور. این مقاله بر کشینگ فرانت‌اند تمرکز دارد، به ویژه بر چگونگی بهره‌برداری از کش HTTP داخلی مرورگر و کش پیشرفته‌تر Service Worker.

کشینگ HTTP: بهره‌گیری از قابلیت‌های مرورگر

کشینگ HTTP مکانیسم داخلی مرورگر برای ذخیره و بازیابی منابع است. این فرآیند توسط هدرهای HTTP که توسط سرور در پاسخ به یک درخواست ارسال می‌شوند، کنترل می‌شود. این هدرها دستورالعمل‌هایی را به مرورگر در مورد مدت زمان کش کردن یک منبع و شرایطی که تحت آن باید معتبر در نظر گرفته شود، ارائه می‌دهند.

هدرهای کلیدی کش HTTP

• Cache-Control: این مهم‌ترین هدر برای کنترل کشینگ HTTP است. به شما امکان می‌دهد دستورالعمل‌های مختلفی را مشخص کنید، مانند:
• max-age=seconds: حداکثر زمانی که یک منبع تازه (fresh) در نظر گرفته می‌شود را مشخص می‌کند. پس از این زمان، مرورگر باید کش را با سرور مجدداً اعتبارسنجی کند. مثال: Cache-Control: max-age=3600 (کش برای ۱ ساعت).
• s-maxage=seconds: مشابه max-age است، اما به طور خاص برای کش‌های اشتراکی مانند CDNها اعمال می‌شود. مثال: Cache-Control: max-age=3600, s-maxage=86400 (کش برای ۱ ساعت در مرورگر، ۱ روز در CDN).
• public: نشان می‌دهد که پاسخ می‌تواند توسط هر کشی، از جمله کش‌های اشتراکی، کش شود.
• private: نشان می‌دهد که پاسخ فقط می‌تواند توسط مرورگر کش شود و نه توسط کش‌های اشتراکی. برای داده‌های مختص کاربر مفید است.
• no-cache: مرورگر را مجبور می‌کند تا قبل از استفاده از کش، حتی اگر هنوز تازه باشد، آن را با سرور مجدداً اعتبارسنجی کند.
• no-store: از کش شدن پاسخ توسط مرورگر به طور کلی جلوگیری می‌کند.
• Expires: یک هدر قدیمی‌تر که تاریخ و زمان مطلقی را که منبع منقضی می‌شود، مشخص می‌کند. اگر هر دو هدر Cache-Control و Expires وجود داشته باشند، معمولاً Cache-Control ارجحیت دارد. مثال: Expires: Wed, 21 Oct 2024 07:28:00 GMT
• ETag: یک شناسه منحصربه‌فرد برای یک نسخه خاص از یک منبع. مرورگر در هنگام اعتبارسنجی مجدد، ETag را در هدر درخواست If-None-Match ارسال می‌کند. اگر منبع تغییر نکرده باشد، سرور پاسخ 304 Not Modified را برمی‌گرداند، که نشان می‌دهد مرورگر می‌تواند از نسخه کش‌شده استفاده کند.
• Last-Modified: آخرین زمانی که منبع اصلاح شده است را نشان می‌دهد. مرورگر در هنگام اعتبارسنجی مجدد، تاریخ Last-Modified را در هدر درخواست If-Modified-Since ارسال می‌کند. مشابه ETag، اگر منبع تغییر نکرده باشد، سرور می‌تواند پاسخ 304 Not Modified را برگرداند.

مثال‌های عملی از کشینگ HTTP

مثال ۱: کش کردن دارایی‌های ثابت (تصاویر، CSS، جاوا اسکریپت):

برای دارایی‌های ثابتی که به ندرت تغییر می‌کنند، می‌توانید یک مقدار طولانی برای max-age تنظیم کنید:

            Cache-Control: public, max-age=31536000  

            

              
                Copy
              
            
          

این به مرورگر می‌گوید که منبع را برای یک سال (۳۱,۵۳۶,۰۰۰ ثانیه) کش کند و اینکه می‌تواند توسط هر کشی (public) کش شود.

مثال ۲: کش کردن محتوای پویا با اعتبارسنجی مجدد:

برای محتوای پویایی که بیشتر تغییر می‌کند، می‌توانید از no-cache به همراه ETag یا Last-Modified برای اعتبارسنجی مجدد استفاده کنید:

            Cache-Control: no-cache, must-revalidate
ETag: "unique-etag-value"

            

              
                Copy
              
            
          

این مرورگر را مجبور می‌کند تا قبل از استفاده از کش، آن را با سرور اعتبارسنجی مجدد کند. سپس سرور می‌تواند از ETag برای تعیین اینکه آیا منبع تغییر کرده است یا نه، استفاده کند و در صورت عدم تغییر، پاسخ 304 Not Modified را برگرداند.

مثال ۳: ارائه دارایی‌های نسخه‌بندی شده:

یک روش رایج، گنجاندن یک شماره نسخه در نام فایل دارایی است (مثلاً style.v1.css). هنگامی که دارایی تغییر می‌کند، شما شماره نسخه را به‌روز می‌کنید و مرورگر را مجبور به دانلود نسخه جدید می‌کنید. این به شما امکان می‌دهد تا دارایی‌ها را به شدت کش کنید بدون اینکه نگران ارائه محتوای قدیمی باشید.

بهترین شیوه‌ها برای کشینگ HTTP

• از CDN استفاده کنید: شبکه‌های تحویل محتوا (CDN) محتوای وب‌سایت شما را در سرورهای متعددی که از نظر جغرافیایی به کاربران نزدیک‌تر هستند توزیع می‌کنند. این امر تأخیر را کاهش داده و زمان بارگذاری را بهبود می‌بخشد، به ویژه برای کاربرانی که در نقاط مختلف جهان هستند. CDNهای محبوب شامل Cloudflare، Akamai و Amazon CloudFront هستند. وب‌سایتی در ژاپن که تصاویر را از سروری در اروپا بارگذاری می‌کند، از یک CDN با سرورهایی در آسیا بهره زیادی خواهد برد.
• از کش مرورگر بهره ببرید: سرور خود را طوری پیکربندی کنید که هدرهای کش HTTP مناسب را برای تمام منابع شما ارسال کند.
• از تکنیک‌های cache busting استفاده کنید: از تکنیک‌هایی مانند نسخه‌بندی یا پارامترهای کوئری برای مجبور کردن مرورگرها به دانلود منابع به‌روز شده هنگام تغییر آنها استفاده کنید.
• عملکرد کش را نظارت کنید: از ابزارهای توسعه‌دهنده مرورگر و تحلیل‌های سمت سرور برای نظارت بر نرخ موفقیت کش (cache hit rates) و شناسایی زمینه‌های بهبود استفاده کنید.

کش Service Worker: کنترل پیشرفته و قابلیت‌های آفلاین

Service Workerها فایل‌های جاوا اسکریپتی هستند که در پس‌زمینه، جدا از رشته اصلی مرورگر، اجرا می‌شوند. آنها به عنوان یک پراکسی بین مرورگر و شبکه عمل می‌کنند و به شما امکان می‌دهند درخواست‌های شبکه را رهگیری کرده و استراتژی‌های کشینگ پیشرفته را پیاده‌سازی کنید.

Service Workerها یک فناوری کلیدی در پس اپلیکیشن‌های وب پیش‌رونده (PWA) هستند و ویژگی‌هایی مانند دسترسی آفلاین، اعلان‌های فشاری (push notifications) و همگام‌سازی پس‌زمینه را امکان‌پذیر می‌سازند.

نحوه کار Service Workerها

1. ثبت (Registration): سرویس‌ورکر توسط صفحه وب شما ثبت می‌شود.
2. نصب (Installation): سرویس‌ورکر در مرورگر نصب می‌شود. معمولاً در این مرحله منابع ضروری را پیش‌کش (precache) می‌کنید.
3. فعال‌سازی (Activation): سرویس‌ورکر فعال می‌شود و شروع به کنترل درخواست‌های شبکه برای صفحات درون دامنه خود می‌کند.
4. رهگیری (Interception): سرویس‌ورکر درخواست‌های شبکه را رهگیری می‌کند و می‌تواند انتخاب کند که منابع را از کش ارائه دهد، آنها را از شبکه واکشی کند، یا حتی یک پاسخ ترکیبی ایجاد کند.

APIهای کلیدی Service Worker برای کشینگ

• Cache API: مکانیزمی برای ذخیره و بازیابی پاسخ‌های کش‌شده فراهم می‌کند. به شما امکان می‌دهد کش‌های نام‌گذاری شده ایجاد کنید و ورودی‌ها را اضافه، به‌روزرسانی و حذف کنید.
• Fetch API: برای ایجاد درخواست‌های شبکه از داخل Service Worker استفاده می‌شود.
• addEventListener('install', ...): کنترل‌کننده رویدادی که هنگام نصب اولیه سرویس‌ورکر اجرا می‌شود. این رویداد معمولاً برای پیش‌کش کردن دارایی‌های مهم استفاده می‌شود.
• addEventListener('activate', ...): کنترل‌کننده رویدادی که هنگام فعال شدن سرویس‌ورکر اجرا می‌شود. این رویداد معمولاً برای پاک‌سازی کش‌های قدیمی استفاده می‌شود.
• addEventListener('fetch', ...): کنترل‌کننده رویدادی که درخواست‌های شبکه را رهگیری می‌کند. منطق کشینگ در اینجا قرار می‌گیرد.

استراتژی‌های کشینگ با Service Workerها

Service Workerها به شما امکان می‌دهند استراتژی‌های کشینگ مختلفی را متناسب با انواع مختلف منابع و شرایط شبکه پیاده‌سازی کنید. در اینجا برخی از استراتژی‌های رایج آورده شده است:

• اول کش (Cache First): همیشه منبع را از کش ارائه دهید اگر در دسترس باشد. اگر در کش نباشد، آن را از شبکه واکشی کرده و برای استفاده‌های بعدی در کش ذخیره کنید. این استراتژی برای دارایی‌های ثابتی که به ندرت تغییر می‌کنند ایده‌آل است.
• اول شبکه (Network First): همیشه ابتدا سعی کنید منبع را از شبکه واکشی کنید. اگر شبکه در دسترس باشد، منبع را ارائه داده و کش را به‌روز کنید. اگر شبکه در دسترس نباشد، منبع را از کش ارائه دهید. این برای محتوای پویایی که باید تا حد امکان به‌روز باشد مناسب است.
• کش، سپس شبکه (Cache, then Network): منبع را فوراً از کش ارائه دهید و همزمان آخرین نسخه را از شبکه واکشی کنید. هنگامی که نسخه جدید رسید، کش را با آن به‌روز کنید. این روش بارگذاری اولیه سریع را فراهم می‌کند و تضمین می‌کند که کاربر در نهایت جدیدترین محتوا را دریافت می‌کند.
• کهنه-حین-اعتبارسنجی (Stale-While-Revalidate): منبع را فوراً از کش ارائه دهید. در پس‌زمینه، آخرین نسخه را از شبکه واکشی کرده و کش را به‌روز کنید. دفعه بعد که منبع درخواست شود، نسخه به‌روز شده ارائه خواهد شد. این استراتژی بارگذاری اولیه سریع را فراهم می‌کند و تضمین می‌کند که کاربر همیشه در نهایت جدیدترین نسخه را دریافت می‌کند، بدون اینکه درخواست اولیه مسدود شود.
• فقط شبکه (Network Only): همیشه منبع را از شبکه واکشی کنید. هرگز از کش استفاده نکنید. این برای منابعی مناسب است که هرگز نباید کش شوند، مانند داده‌های حساس کاربر.
• فقط کش (Cache Only): همیشه منبع را از کش ارائه دهید. هرگز آن را از شبکه واکشی نکنید. این برای سناریوهایی مفید است که می‌خواهید اطمینان حاصل کنید منبع همیشه به صورت آفلاین در دسترس است.

مثال‌های عملی از کشینگ Service Worker

مثال ۱: استراتژی Cache First برای دارایی‌های ثابت:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Cache hit - return response
        if (response) {
          return response;
        }

        // Not in cache - fetch from network
        return fetch(event.request).then(
          response => {
            // Check if we received a valid response
            if (!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANT: Clone the response. A response is a stream
            // and because we want the browser to consume the response
            // as well as the cache consuming the response, we need
            // to clone it.
            const responseToCache = response.clone();

            caches.open('my-site-cache')
              .then(cache => {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
  );
});

            

              
                Copy
              
            
          

این قطعه کد استراتژی Cache First را نشان می‌دهد. Service Worker ابتدا بررسی می‌کند که آیا منبع درخواستی در کش موجود است یا خیر. اگر باشد، منبع را از کش ارائه می‌دهد. اگر نباشد، منبع را از شبکه واکشی کرده، آن را در کش ذخیره می‌کند و سپس به مرورگر ارائه می‌دهد.

مثال ۲: استراتژی Stale-While-Revalidate برای محتوای پویا:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open('my-site-cache').then(cache => {
      return cache.match(event.request).then(response => {
        const fetchPromise = fetch(event.request).then(networkResponse => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return response || fetchPromise;
      })
    })
  );
});

            

              
                Copy
              
            
          

این قطعه کد استراتژی Stale-While-Revalidate را نشان می‌دهد. Service Worker منبع را فوراً از کش ارائه می‌دهد. در پس‌زمینه، آخرین نسخه را از شبکه واکشی کرده و کش را به‌روز می‌کند. دفعه بعد که منبع درخواست شود، نسخه به‌روز شده ارائه خواهد شد.

بهترین شیوه‌ها برای کشینگ Service Worker

• از یک کتابخانه استراتژی کشینگ استفاده کنید: کتابخانه‌هایی مانند Workbox توسعه Service Worker را با ارائه استراتژی‌های کشینگ از پیش ساخته شده و ابزارهای کمکی ساده می‌کنند. این می‌تواند در وقت و تلاش شما صرفه‌جویی کرده و اطمینان حاصل کند که منطق کشینگ شما قوی و قابل اعتماد است.
• نسخه‌های کش را مدیریت کنید: هنگامی که Service Worker خود را به‌روز می‌کنید، باید کش قدیمی را باطل کرده و یک کش جدید ایجاد کنید. این از ارائه منابع قدیمی جلوگیری می‌کند. از رویداد activate برای پاک‌سازی کش‌های قدیمی استفاده کنید.
• خطاها را به خوبی مدیریت کنید: مدیریت خطا را برای رسیدگی به شکست‌های شبکه و عدم وجود منبع در کش (cache misses) پیاده‌سازی کنید. محتوای جایگزین ارائه دهید یا به کاربر اطلاع دهید که منبع در دسترس نیست.
• به طور کامل تست کنید: منطق کشینگ Service Worker خود را در شرایط مختلف شبکه و محیط‌های مرورگر آزمایش کنید تا اطمینان حاصل کنید که مطابق انتظار کار می‌کند. از ابزارهای توسعه‌دهنده مرورگر برای بازرسی کش و نظارت بر درخواست‌های شبکه استفاده کنید.
• تجربه کاربری را در نظر بگیرید: استراتژی کشینگ خود را با در نظر گرفتن تجربه کاربری طراحی کنید. هنگامی که یک منبع از شبکه یا کش واکشی می‌شود، به کاربر بازخورد دهید. از ارائه محتوای کهنه برای مدت طولانی خودداری کنید.

مقایسه کش HTTP و کش Service Worker

در حالی که هر دو کشینگ HTTP و کشینگ Service Worker با هدف بهبود عملکرد وب‌سایت انجام می‌شوند، در قابلیت‌ها و موارد استفاده خود متفاوت هستند.

ملاحظات جهانی برای کشینگ

هنگام پیاده‌سازی استراتژی‌های کشینگ برای مخاطبان جهانی، موارد زیر را در نظر بگیرید:

• شرایط شبکه: کاربران در مناطق مختلف ممکن است سرعت و قابلیت اطمینان شبکه متفاوتی را تجربه کنند. استراتژی کشینگ خود را برای سازگاری با این تفاوت‌ها تطبیق دهید. به عنوان مثال، کاربران در مناطقی با دسترسی غیرقابل اعتماد به اینترنت از پشتیبانی قوی آفلاین بهره زیادی خواهند برد.
• پوشش CDN: یک CDN با شبکه جهانی از سرورها را انتخاب کنید تا اطمینان حاصل شود که محتوای شما به سرعت به کاربران در تمام مناطق تحویل داده می‌شود. بررسی کنید که CDN دارای نقاط حضور (PoPs) در مناطق حیاتی برای مخاطبان شما باشد.
• حریم خصوصی داده‌ها: هنگام کش کردن داده‌های مختص کاربر، به مقررات حریم خصوصی داده‌ها در کشورهای مختلف توجه داشته باشید. اطمینان حاصل کنید که با قوانینی مانند GDPR و CCPA مطابقت دارید.
• زبان و بومی‌سازی: کش کردن نسخه‌های بومی‌سازی شده وب‌سایت خود را برای ارائه تجربه کاربری بهتر برای کاربران در زبان‌ها و مناطق مختلف در نظر بگیرید.
• ابطال کش: یک استراتژی قابل اعتماد برای ابطال کش پیاده‌سازی کنید تا اطمینان حاصل شود که کاربران همیشه جدیدترین محتوا را دریافت می‌کنند، حتی زمانی که به طور مکرر تغییر می‌کند. به به‌روزرسانی‌های محتوای بومی‌سازی شده توجه ویژه داشته باشید.

نتیجه‌گیری

کشینگ فرانت‌اند یک تکنیک ضروری برای بهینه‌سازی عملکرد وب‌سایت و بهبود تجربه کاربری است. با بهره‌گیری از کشینگ HTTP و کشینگ Service Worker، می‌توانید زمان بارگذاری را به طور قابل توجهی کاهش دهید، بار سرور را کم کنید و دسترسی آفلاین به محتوای وب‌سایت خود را فراهم کنید. هنگام انتخاب و پیاده‌سازی استراتژی‌های کشینگ، نیازهای خاص وب‌سایت و مخاطبان هدف خود را به دقت در نظر بگیرید. با اتخاذ بهترین شیوه‌ها و نظارت مستمر بر عملکرد کشینگ خود، می‌توانید اطمینان حاصل کنید که وب‌سایت شما تجربه‌ای سریع و قابل اعتماد را برای کاربران در سراسر جهان ارائه می‌دهد.